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DETAILED ACTION 

1. Acknowledgement is made of Applicant's amendment dated 18 March 2005, responding 
to the 3 January 2005 Office action provided in the rejection of claims 1-13, wherein no claims 
have been amended, canceled, or added. Claims 1-13 remain pending in the application and 
have been fiilly considered by the examiner. 

2. Applicant's amendment attempted to overcome the 35 USC 102 and 103 rejections by 
way of a declaration filed under 37 CFR 1.131. However, the declaration was ineffective to 
overcome the references, as explained in the "Declaration - 37 CFR 1.131" section below. 

3. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS fi-om the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated fi-om the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS firom the mailing 
date of this final action. 

Declaration - 3 7 CFR 1.131 

4. The declaration filed on 1 8 March 2005 under 37 CFR 1 . 1 3 1 has been considered but is 
ineffective to overcome the "McLaughlin-3" or "McLaughlin-4" references. Applicant has 



Application/Control Number: 09/837,929 Page 3 

Art Unit: 2192 

attempted to show conception of the invention prior to January 26, 2000, coupled with diligence 
from September 2000 (date of the McLaughlin-3 reference) to April 19, 2001 (date of filing). 

The essential thing to be shown imder 37 CFR 1.131 is priority of invention and this may 
be done by any satisfactory evidence of the fact. Any exhibit relied upon to provide such 
evidence should be specifically referred to in the declaration, in terms of what it is relied 
upon to show. A general allegation that the invention was completed prior to January 26 2000 is 
not sufficient. Ex parte Saunders, 1883 CD. 23, 23 O.G. 1224 (Comm'r Pat. 1883). Similarly, a 
declaration by the inventor to the effect that his or her invention was conceived or reduced to 
practice prior to September 2000 {McLaughlin-3\ without a statement of facts demonstrating 
the correctness of this conclusion, is insufficient to satisfy 37 CFR 1.131. An accompanying 
exhibit need not support all claimed limitations, provided that any missing limitation is supported 
by the declaration itself Ex parte Ovshinsky, 10 USPQ2d 1075 (Bd. Pat. App. & Inter. 1989). 
The declaration must clearly explain which facts or data applicant is relying on to show 
completion of his or her invention prior to September 2000. Vague and general statements in 
broad terms about what the exhibits describe along with a general assertion that the exhibits 
describe a reduction to practice "amounts essentially to mere pleading, unsupported by proof or a 
showing of facts" and, thus, does not satisfy the requirements of 37 CFR 1.131(b). In re 
Borkowski, 505 F.2d 713, 184 USPQ 29 (CCPA 1974). Applicant must give a clear explanation 
of the exhibits pointing out exactly what facts are established and relied on by appUcant. 505 
F.2d at 718-19, 184 USPQ at 33. See also In re Harry, 333 F.2d 920, 142 USPQ 164 (CCPA 
1964) (Affidavit "asserts that facts exist but does not tell what they are or when they occurred."). 
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In order to show prior invention by way of conception, the showing of facts must be 
sufficient to show: 

(A) Conception of the invention prior to the effective date of the reference 
coupled with due diligence from prior to the reference date to a subsequent (actual) 
reduction to practice; or 

(B) Conception of the invention prior to the effective date of the reference 
coupled with due diligence from prior to the reference date to the filing date of the 
application (constructive reduction to practice). 

The declaration filed on 19 November 2004 merely asserts that conception existed prior 
to January 26, 2000. Several documents are provided in an attempt to support this date of 
conception. However, the declaration does not meet the requirements for providing exhibits 
since it does not specifically refer to each exhibit in terms of what it is relied upon to show, 
nor does it clearly explain which facts or data applicant is relying upon to show conception of the 
invention prior to January 26 2000 coupled with due diligence from September 2000 
(McLaughlin-S) to April 19 2001 (date of filing). If supported by an appropriate declaration or 
affidavit, the seven page document entitled "A Mechanism for Converting Between Java Classes 
and XML" would appear to be sufficient to show conception. However, conception of the 
invention has not been sufficiently shown, and thus the declaration is ineffective to overcome the 
McLaughlin-3 and McLaughlin-4 references. 

In the interest of compact prosecution, it is noted that due diligence has not been 
established through a clear explanation of any periods of inactivity. Since conception of the 
invention has not been clearly established, due diligence has not been considered. Thus, this 
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observation is merely exemplary and is not comprehensive. In determining the sufficiency of a 
37 CFR 1.131 affidavit or declaration, diligence need not be considered unless conception of the 
invention prior to the effective date is clearly established, since diligence comes into question 
only after prior conception is established. Ex parte Kantor, 111 USPQ 455 (Bd. App. 1958). 
Also see MPEP 715.07(a). 

Applicant has submitted numerous documents and has provided an identifying 
description of the documents in the declaration. However, the associated description in the 
declaration merely provides a description of the document (e.g. "the attached e-mail dated 
January 26, 2000. . .was written by me", "it is an accurate copy of the e-mail I received", etc.), 
and does not specifically refer to each exhibit in terms of what it is relied upon to show, nor 
does it clearly explain which facts or data applicant is relying on. The examiner is required to 
make a legal determination based upon the facts submitted in the declaration. While the 
associated documents may or may not provide sufficient support for conception of the invention 
or due diligence, the decision is made based upon the statements found in the declaration. 
Without a clear explanation of which facts or data applicant is relying on to show completion of 
the claimed invention prior to a particular date, a declaration is not sufficient to overcome a 
reference. 

Furthermore, appUcant refers to a document entitled "A Mechanism For Converting 
Between Java Classes and XML" (THE DOCUMENT) as support for conception of the 
invention, and alleges that it was attached in an email sent on January 26, 2000 as submitted in 
the declaration in items (1) and (2). However, two attached exhibits by that name were 
submitted and are dated 07/30/2004, and Feb-22-2005, respectively. It is not clear if either these 
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documents are copies of the same version that was attached to the email sent of January 26, 
2000. Clarification is needed to clarify if either or both of these later dated copies are the same 
version of THE DOCUMENT that was attached to the email dated January 26, 2000. 

Claim Rejections - 35 USC§102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this 
or a foreign country, before the invention thereof by the applicant for a patent. 

6. Claim 2 is rejected under 35 U.S.C. 102(a) as being anticipated by prior art of record 
"Data Binding fi-om XML to Java, Part 3" by McLaughlin, published September 2000 
(hereinafter referred to as "McLaughlin-3"). 

The text of the rejection of claim 2 below is reproduced for convenience from the 
previous Office action filed 3 January 2005. 

In regard to claim 2, McLaughhn-3 discloses: 

instantiating an object of a desired object-oriented programming language class 
(See page 3 paragraph 2: "Once a new instance of the appropriate class is created. . ."); 

in the case of said instantiated object, implementing a predefined interface (See 
page 3 paragraph 2: "Once a new instance of the appropriate class is created, the mutator 
methods are called with the values supplied in the XML dociunent." The mutator 
methods are part of a predefined interface for setting attribute values. Listing 3 on page 3 
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shows the corresponding implementation of a mutator method. Mutator methods are 
commonly used for setting attribute values.), 

iteratively processing each object included within said instantiated object (See page 4 
paragraph 4: "Once all the attributes are read and assigned to the created Java instance, 
you need to take each.nested element and perform the unmarshalling again.") 
according to the steps of: 

retrieving field descriptors associated with said object being processed (See page 
4 paragraph 3: "Finally, the nested objects are passed to accessor methods, and the top- 
level object, which is populated with both member variable values and object references, 
is returned to the calling program." Accessor methods are commonly used to retrieve 
attribute values including field descriptors.); 

creating an object of a specified desired object-oriented programming language 
type for each XML element corresponding to a field descriptor (See McLaughlin-3 page 
3 paragraph 2: "Once a new instance of the appropriate class is created, the mutator 
methods are called with the values supplied in the XML document."; also page 4 
paragraph 4: "Once all the attributes are read and assigned to the created Java instance, 
you need to take each nested element and perform the unmarshalling again." ); and 

storing the created object in the currently processed object (See page 4 paragraph 
4: "Once all the attributes are read and assigned to the created Java instance. . ."). 
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Claim Rejections - 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this 0£5ce action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

8. Claims 1 and 3-9 are rejected under 35 U.S.C. 103(a) as being unpatentable over prior art 
of record "Data Binding from XML to Java, Part 4" by McLaughlin published on October 1, 
2000 (hereinafter referred to as "McLaughlin-4") in view of McLaughlin-3. 

The text of the rejections of claims 1 and 3-9 below is reproduced for convenience from 
the previous Office action filed 19 May 2004, in hght of the amendment filed 10 September 
2004. 



As per claim 1, McLaughlin-4 discloses: 

loading the named object-oriented programming language class (See page 2 
paragraph 7: "It takes an object and should return an XML element representation of that 
object." An object is inherently loaded from an object-oriented programming language 
class.); 

determining if the loaded object-oriented programming language class 
implements a predefined interface (See page 2 paragraph 5: "Any data fields without 
accessor methods like this will result in that data being ignored in the process of 
marshalling." If it is determined that an object-oriented programming language class 
does not implement a predefined interface including accessor methods, it is ignored.). 
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said predefined interface comprising annotations including associating said 
object-oriented programming language class field with a corresponding XML element 
tag (See McLaughlin-4 page 3 paragraph 2: "Once the element name is in place, you 
must obtain the attributes. Each attribute should be the name of the field and the field's 
value." ) 

specifying an object-oriented programming language class to be instantiated 
when constructing said object-oriented programming language class field from said XML 
file (See McLaughlin-4 page 3 paragraph 1 : "First, the name of the Java class is obtained. 
This name will become the element name of the XML representation being constructed.") 

identijying an object-oriented programming language method to invoke for 
retrieving said object-oriented programming language class field (See McLaughlin-4 
page 2 paragraph 5: ". . .it is expected to have accessor methods for all of its data." 
Accessor methods are known for retrieving class fields.), and, 

in the case of said loaded object-oriented programming language class 
implementing said predefined interface 

iteratively processing each field descriptor within the loaded object-oriented 
programming language class to retrieve corresponding XML tag (See McLaughlin-4 
page 2 paragraph 7: "It takes an object and should retum an XML element 
representation of that object. If the object contains references to other Java objects, then 
you can recurse..." As noted earlier, if the accessor method is not implemented, the 
descriptor is ignored.); and 
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transferring field values to new elements created using said corresponding XML 
tags (See McLaughlin-4 page 4 paragraph 1: "And once the recursion unwinds, the result 
is a complete XML representation of the top-level Java object, which is usable as a root 
element in an XML document." Field values are inherently transferred to the resulting 
XML representation.). 

McLaughlin-4 also discloses the use of parameters in defining the marshalling 
function (See page 3, Listing 2 for the definition of "getXMLRepresentation"). 

McLaughlin-4 does not expressly disclose defining a method with four 
parameters, or identifying a JAVA method to invoke for retrieving this method. 

However, official notice is taken that the use of parameters in method and 
interface definitions is known in the art. An arbitrary number of parameters can be used 
in the definition of a method depending on the scope of the data being operated upon, and 
the requirements of the method or interface. Parameters are used in method and interface 
definitions on occasions where proper data values are not available to the called method. 

Further, in an analogous environment, McLaughlin-3 teaches using an interface 
including mutator methods which convert data stored in an XML representation of a Java 
class instance, into a new Java instance of the same respective class (See page 3 
paragraph 2: "Once a new instance of the appropriate class is created, the mutator 
methods (all named setXXX) are called with the values supplied in the XML document." 
According to McLaughlin's interface, the Java method to invoke for retrieving this 
method is standardized based on the name of the attribute.). The mutator method is 
inherently identified for retrieval purposes. 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the marshalling method of McLaughlin-4 with the derived 
mutators of McLaughlin-3 and additional parameters. One of ordinary skill would have 
been motivated to provide two-way conversions not only from Java to XML, but also 
from XML to Java by using mutators to initialize data members in an object instance. 
One would have also been motivated to use parameters to pass data to methods which 
would otherwise be out of scope. 

As per claim 3, McLaughlin-4 discloses: 

annotating said object-oriented programming language object to be converted to 
said XML to include the steps of: 

identifying a respective XML tag (See page 3 paragraph 2: "Once the element 
name is in place, you must obtain the attributes. Each attribute should be the name of 
the field and the field's value." The name of Java attributes are inherently annotated 
within the Java object.); 

identifying an object-oriented programming language class to be instantiated 
when constructing said object-oriented programming language object field fi^om an XML 
file, (See page 3 paragraph 1: "First, the name of the Java class is obtained. This name 
will become the element name of the XML representation being constructed."); and 

identifying an object-oriented programming language method to invoke for 
retrieving said object-oriented programming language object (See page 2 paragraph 5: 
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. .it is expected to have accessor methods for all of its data." Accessor methods are 
known for retrieving objects.). 

McLaughlin-4 does not expressly disclose identifying an object-oriented 
programming language method to invoke for retrieving said retrieval method. 

However, in an analogous environment, McLaughlin-3 teaches using an interface 
including mutator methods which convert data stored in an XML representation of a Java 
class instance, into a new Java instance of the same respective class (See page 3 
paragraph 2: "Once a new instance of the appropriate class is created, the mutator 
methods (all named setXXX) are called with the values supplied in the XML docimient." 
According to McLaughlin's interface, the Java method to invoke for retrieving this 
method is standardized based on the name of the attribute.). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the marshalling method of McLaughlin-4 with the derived 
mutators of McLaughlin-3. One of ordinary skill would have been motivated to provide 
for future unmarshalling of a marshaled object. 

As per claim 4, McLaughlin-4 discloses: 

retrieving a field description; determining object-oriented programming language 
conversion parameters 

by examining an annotation associated with each object-oriented programming language 
element to be converted to XML (See McLaughlin-4 page 2 paragraph 7: "It takes an 
object and should return an XML element representation of that object. If the object 
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contains references to other Java objects, then you can recurse..." The examination of 
annotations is inherent when processing objects.), 

said annotation defining for each object-oriented programming language element 
at least a corresponding XML tag, a corresponding object class (See McLaughlin-4 page 
3 paragraph 1 : "First, the name of the Java class is obtained. This name will become the 
element name of the XML representation being constructed."), and 

a corresponding field retrieval method (See McLaughlin-4 page 2 paragraph 5: 
. .it is expected to have accessor methods for all of its data." Accessor methods are 
known for retrieving objects fields.). 

McLaughlin-4 does not expressly disclose a corresponding method retrieval 
method. 

However, in an analogous environment, McLaughlin-3 teaches using an interface 
including mutator methods which convert data stored in an XML representation of a Java 
class instance, into a new Java instance of the same respective class (See page 3 
paragraph 2: "Once a new instance of the appropriate class is created, the mutator 
methods (all named setXXX) are called with the values supplied in the XML document." 
According to McLaughlin's interface, the Java method to invoke for retrieving this 
method is standardized based on the name of the attribute.). The mutator method is 
inherently identified for retrieval purposes. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the marshalling method of McLaughlin-4 with the derived 
mutators of McLaughlin-3. One of ordinary skill would have been motivated to provide 
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two-way conversions not only from Java to XML, but also from XML to Java by using 
mutators to retrieve methods to initialize data members in an object instance. 

As per claim 5, the rejection of claim 4 is incorporated, and McLaughlin further 
discloses: 

loading a named object-oriented programming language class (See McLaughlin- 
4 page 2 paragraph 7: "It takes an object and should return an XML element 
representation of that object/' An object is inherently loaded from a JAVA class.); 

determining if a loaded object-oriented programming language class implements 
a predefined interfizce (See McLaughlin-4 page 2 paragraph 5: "Any data fields without 
accessor methods like this will result in that data being ignored in the process of 
marshalling." If it is detemiined that a JAVA class does not implement accessor 
methods, it is ignored.), 

in the case of said loaded object-oriented programming language class 
implementing said predefined interface 

iteratively processing each field descriptor within the loaded object-oriented 
programming language class to retrieve the 

corresponding XML tag (See McLaughlin-4 page 2 paragraph 7: "It takes an object and 
should retum an XML element representation of that object. If the object contains 
references to other Java objects, then you can recurse..." As noted earlier, if the accessor 
method is not implemented, the descriptor is ignored.); and 

transferring field values to new elements created using said corresponding XML 
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tags (See McLaughlin-4 page 4 paragraph 1: "And once the recursion unwinds, the result 
is a complete XML representation of the top-level Java object, which is usable as a root 
element in an XML document."). . 

McLaughlan-4 does not expressly disclose defining a method with four 
parameters. 

However, official notice is taken that the use of parameters in method and 
interface defmitions is known in the art. An arbitrary number of parameters can be used 
in the definition of a method depending on the scope of the data being operated upon, and 
the requirements of the method or interface. Parameters are used in method and interface 
definitions on occasions where proper data values are not available to the called method. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the marshalling method of McLaughlin-4 with additional 
parameters. One of ordinary skill would be motivated to provide the marshalling method 
with any data that a programmer would want to persist. 

As per claim 6, the rejection of claim 4 is incorporated, and McLaughlin-4 further 

discloses: 

instantiating an object of a desired object-oriented programming language class 
(See McLaughlin-4 page 2 paragraph 7: "It takes an object and should retum an XML 
element representation of that object." An object is inherently instantiated fi-om a JAVA 
class); 
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in the case of said instantiated object implementing a predefined interface (See 
McLaughlin-4 page 2 paragraph 5: "Any data fields without accessor methods Uke this 
will result in that data being ignored. . ."), 

iteratively processing each object included within said instantiated object (See 
McLaughlin-4 page 2 paragraph 7: "If the object contains references to other Java 
objects, then you can recurse. . 

according to the steps of: 

retrieving field descriptors associated with an object being processed (See 
McLaughlin-4 page 3 paragraph 2: "Once the element name is in place, you must obtain 
the attributes. Each attribute should be the name of the field and the field's value."); 

McLaughlin-4 does not expressly disclose creating a specified Java object for 
each XML element, and storing that object. 

However, McLaughlin-3 teaches: creating an object of specified object-oriented 
programming language type for each XML element corresponding to a field descriptor 
(See McLaughlin-3 page 3 paragraph 2: "Once a new instance of the appropriate class is 
created, the mutator methods are called with the values supplied in the XML document."; 
also page 4 paragraph 4: "Once all the attributes are read and assigned to the created Java 
instance, you need to take each nested element and perform the unmarshalling again." ); 
and 

storing the created object in the currently processed object (See McLaughlin-3 page 4 
paragraph 4: "Once all the attributes are read and assigned to the created Java instance). 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the object processing of McLaughlin-4 with the XML 
translation of McLaughhn-3. One of ordinary skill would have been motivated store an 
accurate and complete representation of an object that could easily be sent through a 
network and reconstituted at a later time. 

As per claim 7, McLaughlin-4 discloses: 

associating said object-oriented programming language class field with a 
corresponding XML element tag (See McLaughlin-4 page 3 paragraph 1: "First, the name 
of the Java class is obtained. This name will become the element name of the XML 
representation being constructed."); 

specifying an object-oriented programming language class to be instantiated 
when constructing said object-oriented programming language class field from said XML 
file (See McLaughlin-4 page 3 paragraph 2: "Once the element name is in place, you 
must obtain the attributes. Each attribute should be the name of the field and the field's 
value."); 

identifying an object-oriented programming language method to invoke for 
retrieving said object-oriented programming language class field (See McLaughlin-4 
page 2 paragraph 5: ". . .it is expected to have accessor methods for all of its data." 
Accessor methods are known for retrieving class fields.). 

McLaughlin-4 also discloses the use of parameters in defining the marshalling 
fimction (See page 3, Listing 2 for the definition of "getXMLRepresentation"). 
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McLaughlin-4 does not expressly disclose the use of four parameters, or 
retrieving the object-oriented programming language class field. 

However, ofificial notice is taken that the use of parameters in method and 
interface definitions is known in the art. An arbitrary number of parameters can be used 
in the definition of a method depending on the scope of the data being operated upon, and 
the requirements of the method or interface. Parameters are used in method and interface 
definitions on occasions where proper data values are not available to the called method. 

Further, in an analogous environment, McLaughlin-3 teaches using an interface 
including mutator methods which convert data stored in an XML representation of a Java 
class instance, into a new Java instance of the same respective class (See page 3 
paragraph 2: "Once a new instance of the appropriate class is created, the mutator 
methods (all named setXXX) are called with the values supplied in the XML document.*' 
According to McLaughlin's interface, the Java method to invoke for retrieving this 
method is standardized based on the name of the attribute. Thus the ability to retrieve a 
field of a class is provided by the mutator methods.). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the marshalling method of McLaughlin-4 with the mutator 
methods of McLaughlin-3 along with multiple parameters. One of ordinary skill would 
have been motivated to provide two-way conversions not only fi-om Java to XML, but 
also fi-om XML to Java by using mutators to initialize data members in an object 
instance. One would have also been motivated to use parameters to pass data to methods 
which would otherwise be out of scope. 
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As per claim 8, the rejection of claim 7 is incorporated. 
McLaughlin-4 discloses the XML representation of Java collections (See page 2 
paragraph 7). 

McLaughlin-4 does not expressly disclose specifying a type of object-oriented 
programming language object to instantiate for an XML element representing a 
collection. 

However, in an analogous environment, McLaughlin-3 teaches conversion of a 
supplied string value in XML to a Java type (See Listing 4, also page 4 paragraph 2: 
"Once this data has been converted to the appropriate type, reflection can be used to 
invoke the accessor method and pass in the converted data type. This enables all 
attributes and their values in the XML document to be stored as method variables and 
values in the resulting Java instance.") 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the marshalling method of McLaughlin-4, with the type 
specification of McLaughlin-3. One of ordinary skill would have been motivated to 
supply type information to an XML representation of a Java class. Strong typing is 
essential to the Java programming language. 

All further limitations have been addressed in the above rejection of claim 7. 

As per claim 9, the rejection of claim 8 is incorporated. 
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McLaughlin-4 further discloses specifying a tag name to use for each element 
representing a collection (See McLaughlin-4 page 3 paragraph 1 : "First, the name of the 
Java class is obtained. This name will become the element name of the XML 
representation being constructed."). 

All fiirther limitations have been addressed in the above rejection of claim 7. 

9. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over McLaughlin-4 in 
view of McLaughlin-3 as applied to claim 8 above, and further in view of "Data Binding from 
XML to Object-oriented programming language Code, Part2" by McLaughlin published in 
August 2000 (hereinafter referred to as "McLaughlin-2"). 

The text of the rejection of claim 10 below is reproduced for convenience from the 
previous Office action filed 19 May 2004 in light of the amendment filed 10 September 2004. 

McLaughlin-4 does not expressly disclose the use of a hash table. 

However, in an analogous environment, McLaughlin-2 teaches the use of a hash 
table in Java to store multiple interfaces and implementations (See page 2 paragraph 5) 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use the collection of McLaughlin-4 with the hash table of 
McLaughlin-2. One of ordinary skill would have been motivated to represent Java 
objects and data in a compact and easily searchable form. 
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10. Claims 1 1-13 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
McLaughlin-4 in view of McLaughlin-3 further in view of U.S. Patent 5,367,685 to Gosling 
(hereinafter referred to as "Gosling"). 

The text of the rejections of claims 11-13 below is reproduced for convenience from the 
previous Office action filed 19 May 2004 in light of the amendment filed 10 September 2004, 

As per claim 1 1, the combination of McLaughlin-4 and McLaughlin-3 does not 
expressly disclose a computer system comprising processing means for executing and 
memory means for storing. 

However, in an analogous environment. Gosling teaches the use of a computer 
system comprising processing means for executing and memory means for storing 
(Figure 2, elements 22 and 24; also column 3 lines 55-57: "As shown in FIG . 2 , 
the exemplary computer system 20 comprises a central 
processing unit (CPU) 22, a memory 24, and an I/O module 

26."). 

All further limitations have been addressed in the above rejection of claim 4. 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to use Gosling's computer system to execute McLaughlin-4's 
marshalling method. One of ordinary skill would have been motivated to execute 
McLaughlin-4's system on a computer system in order to produce a tangible result. 
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As per claims 12 and 13, the above rejection of claim 1 1 is incorporated. All 
further limitations have been addressed in the above rejections of claims 5 and 6, 
respectively. 

Conclusion 

1 1 . Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to J. Derek Rutten whose telephone number is (571) 272-3703. The 
examiner can normally be reached on T-F 6:00 - 4:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tuan Q. Dam can be reached on (571) 272-3695. The fax phone nmnber for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




